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REMARKS/ARGUMENTS 

Applicants submit that the Office Action dated July 9, 2003 is defective because it 
fails to articulate any bases for the rejections contained therein. For this reason the Office 
Action should be withdrawn, and replaced by a new non-final Office Action which property 
articulates the basis for each individual rejection. 

Enablement Rejections 

Specifically, Claims 1-23 stand rejected under 35 U.S.C. 1 12, first paragraph as 
failing to comply with the enablement of "selection software", "assignment software" and 
"solution software". See paragraph 2 at the bottom of page 3 and top of page 4 of the 
above-identified Office Action. In making these enablement rejections, the Examiner did 
not give any reason whatsoever for questioning the adequacy of the Applicants' originally- 
filed application. Instead, the Examiner merely quoted a form statement from the MPEP, 
without explanation its applicability to the "selection software", "assignment software" and 
"solution software." The Examiner did not explain why he/she thinks these particular terms 
are not enabled. 

The Examiner's failure to provide a reason is clear error, as per MPEP 2106.01, 
which is quoted below (emphasis added): 

When basing a rejection on the failure of the applicant's 
disclosure to meet the enablement provisions of the first 
paragraph of 35 U.S.C. 112, the examiner must establish on 
the record that he or she has a reasonable basis for 
questioning the adequacy of the disclosure to enable a 
person of ordinary skill in the art to make and use the 
claimed invention without resorting to undue 
experimentation. See In re Brown, 477 F.2d 946, 177 USPQ 
691 (CCPA 1973); In re Ghiron, 442 F.2d 985, 169 USPQ 
723 (CCPA 1971). Once the examiner has advanced a 
reasonable basis for questioning the adequacy of the 
disclosure, it becomes incumbent on the applicant to rebut 
that challenge and factually demonstrate that his or her 
application disclosure is in fact sufficient. 

of the failure to articulate a basis for the rejection, Applicants submit that the 
enablement rejection should be withdrawn in its entirety. 
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Furthermore, Applicants submit that the three terms "selection software", 
"assignment software" and "solution software" do not occur anywhere in Claims 1-11, 22 
and 23. Therefore, the Examiner must withdraw the 35 U .S.G. 1 1 2 rejection of at least 
these claims. 

In fact the only claims in which these three terms "selection software", "assignment 
software'* and "solution software" are present are Claims 12 and 13 and their dependent 
claims. Assume arguendo that there is a reasonable basis for the rejection (although as 
noted above the Examiner's rejection lacks basis). However, Applicants submit that these 
three terms are in fact enabled throughout the originally filed specification. 

Specifically, Claim 12 explicitly states that the "selection software" is used to select 
a set of active conditional equations at a current analog solution iteration (see page 11 , 
lines 12-13). The selection software Is illustrated in FIG. 1 as being implemented by act 
110 (the relationship between act 110 and selection software is apparent on comparing the 
text in box 110 which is identical to the words of this limitation in Claim 12). Act 110 
implements the summarized description in the specification at page 5 lines 15-16 and at 
page 7 lines 7-8. While act 1 10 of FIG. 1 may itself be implemented in any manner known 
to the skilled artisan, a detailed step-by-step implementation for one illustrative 
embodiment is in fact shown in FIG. 2. Each act in FIG. 2 is individually described by at 
least one sentence in the originally-filed specification at page 7, lines 17-23. These 
sentences are sufficiently enabling to a person of skill in the art. 

To assess the sufficiency of enablement, it is necessary to determine the level of 
skill in the art for the current application. Note that the primary reference used in the prior 
art rejection is the IEEE Standard VHDL Analog and Mixed-Signal Extensions, Std 1076.1- 
1 999, approved 18 March 1999. Therefore, a person skilled in the art of the current 
application is able to understand and write software in conformance with Std 1076.1-1999. 
In addition, the skilled person is sufficiently skilled to understand and apply the teachings 
of all references currently of record in the file history, including the articles mentioned on 
r5SS*!£S!E» P a 9 e 9 and at tne to P °* P 898 10 of tne Offi 0 ® Ac ti° n - Moreover, such a skilled person 
a »'*tSS ma " must be able to understand and write software to implement the inventions described in 
each of U.S. Patents 6,532,569, 6,236,953, 5,548,539, 4,985,860, and 4,868,770 all of 
which were cited in paragraphs 33-37 at page 10 of the Office Action. 
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Therefore, at the above-described level of skill, it is easy to understand how to 
implement two specific steps described in the originally-filed specification at page 7, lines 
17-20 as implementing the "selection software." For example, the specification states that 
step 205 requires the conditions that apply to the conditional equations are evaluated to 
determine which of the conditional equations is active (see page 7, lines 19 and 20). This 
sentence is easily understood (e.g. by referring to the example in Table 1 on page 3) as 
evaluating the conditions in an if-then-else statement. Depending on whichever condition 
is satisfied, one of "then" clauses of the if-then-else statement identifies the "active 
equation." Hence, how to identify an active equation (and by repeating this act how to 
identify a set of active equations) is enabled in the originally-filed specification. 
Applicants submit that anyone with even a minimal amount of software background should 
understand how to implement step 205, simply by checking which of the conditions in the 
"if-then-else" statement is satisfied. 

Also, the specification states in line 20 on page 7 that in step 210 the active 
conditional equations are selected (from among all possible equations). As will be 
apparent at the above-described skill level, selection of any item from a set can be 
performed in any manner, e.g. by setting a flag or driving a signal. For this reason, a 
specific implementation of this step is well within routine engineering. Since each of the 
two steps is enabled, therefore their combination is enabled as well. For this reason, the 
originally-filed specification provides an enabling disclosure of the "selection software." 

Although an illustrative embodiment of the "selection software" has been discussed 
above to demonstrate enablement, Applicants submit that Claim 12 should be interpreted 
more broadly than the illustrative embodiment, because Claim 12 is to be limited only by 
the explicit language recited for the term "selection software" in Claim 12. If prior art is 
found to require a narrower interpretation, then Claim 12 will be amended to appropriately 
recite any additional limitation that may be necessaiy. 

In a similar manner, Applicants submit that the originally-filed specification also 
provides an enabling disclosure of the "assignment software." Specifically, the 
"assignment software" is stated in Claim 12 as being used to assign a value for each active 
conditional equation in the set of active conditional equations to a dynamic slot target 
variable. This claim limitation is illustrated by act 115 in FIG. 1 (see page 7 lines 9-10). 
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Act 1 15 may be implemented in any manner, with an illustrative embodiment shown as 
step 215 in FIG. 2 (described at page 7, line 21). One specific implementation of the 
-assignment software" is described at page 5 lines 10-14 and lines 18-23, wherein it is 
stated that during each iteration an unassigned variable q' is indexed by j, and assignment 
is done one at a time by starting j at 1 and incrementing j after each association. It is clear 
at the above-described skill level how to implement an association for each T- For 
example, each equation (which was identified by "selection software") may be associated 
to a slot in an array (if an array is being used), by storing a pointer to the equation in a 
memory location in the array. Such a specific implementation of this step 21 5 is well within 
routine engineering at the above-described skill level. 

Finally, Applicants submit that the originally-filed specification also provides an 
enabling disclosure of the "solution software." Specifically, the "solution software" is stated 
in Claim 12 as being used to solve the system of simultaneous equations. This claim 
limitation is illustrated by act 120 In FIG. 1 (see page 7 lines 11-12). Act 120 may be 
implemented in any manner, with an illustrative embodiment shown as step 220 in FIG. 2 
(described at page 7, line 22). One specific implementation for solving simultaneous 
equations is described at page 6 lines 2-9 wherein variables are described as being 
substituted into the equations to see if the equations are solved, and If not solved then the 
values are perturbed until a solution is reached. As noted at lines 8-9 on page 6, the 
solution of simultaneous equations is so well known within routine engineering that it is not 
described any further. Methods for solving a system of equations can be found in most 
undergraduate textbooks on numerical mathematics. 

In view of the above, Applicants submit that all three terms "selection software", 
"assignment software" and "solution software" are enabled and therefore the enablement 
rejection of Claims 1 2 and 1 3 and their dependent claims should be withdrawn even if the 
Examiner had articulated a basis for the rejection. 

In addition, Claims 22-23 were rejected as failing to comply with the enablement of 
"translation software." See paragraph 3 at the top of page 4 of the Office Action. Once 
again the Examiner merely quoted a form statement from the MPEP. without explanation 
its applicability to the "translation software". The Examiner did not explain why he/she 
thinks "translation software" is not enabled, and as noted above such failure to articulate a 
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basis is clear error. Assuming there was a basis for the rejection, Applicants submit that 
the translation software is explicitly described in Claim 22 as being used to translate the 
hardware description language description into a system of simultaneous equations (see 
page 13, lines 8-9). Translation of a HDL description into a system of simultaneous 
equations is illustrated in box 435 in FIG. 4 and further described in the specification at 
page 8, lines 10-12. Applicants submit that this description is sufficiently enabling in view 
of the above-described skill level. Therefore, the enablement rejection of Claims 22 and 

23 should be withdrawn. 

That such translators are well known in the art is further evident from the fact that 
the USPTO has granted to the same inventors another patent, namely US Patent 
6,532,569 (compare FIG. 3 therein with FIG. 4 of the current application). Note that the 
translation software was described there in terms similar or identical to the current 
application. 

To summarize, all of four "softwares" mentioned above are believed to be enabled 
In the originally-filed application. If the Examiner continues to make the enablement 
rejection, the Examiner must identify sufficient factual evidence to support a determination 
that a disclosure does not satisfy the enablement requirement and whether any 
experimentation that may be needed is "undue" based on the numerous factors specified 
in MPEP 21 64.01 (a). Moreover, as stated in MPEP 21 64.04 (emphasis added) the 
Examiner's language: 



should focus on those factors, reasons, and evidence that 
lead the examiner to conclude that the specification fails to 
teach how to make and use the claimed invention without 
undue experimentation. This can be done by making 
specific findings of fact, supported bv the evidence, and 
then drawing conclusions based on th ese findings of 
fact. For example, doubt may arise about enablement 
because information is missing about one or more essential 
parts or relationships between parts which one skilled in the 
art could not develop without undue experimentation. In such 
a case, the examiner should specifically identify what 
information is missing and why one skilled in the art could 
not supply the information without undue experimentation. 
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In accordance with the principles of compact prosecution, if 
an enablement rejection is appropriate, the first Office 
action on the merits should present the best case with 
all the relevant reasons, issues, and evidence so that all 
such rejections can be withdrawn if applicant provides 
appropriate convincing arguments and/or evidence in 
rebuttal. Providing the best case in the first Office action will 
also allow the second Office action to be made final should 
applicant fail to provide appropriate convincing arguments 
and/or evidence. Citing new references and/or expanding 
arguments in a second Office action could prevent that 
Office action from being made final. The principles of 
compact prosecution also dictate that if an enablement 
rejection is appropriate and the examiner recognizes 
limitations that would render the claims enabled, the 
examiner should note such limitations to applicant as early in 
the prosecution as possible. 

In other words, the examiner should a lways look for 
enabled, allowable subject matter and co mmunicate to 
applicant what that subject matter is at the earliest point 
possible in the prosecution of the application. 

Applicants submit that in view of the high level of skill (based on the references of record), 
the disclosure is adequate and if any experimentation is required, the experimentation is 
routine. As stated in MPEP 2106, 'The fact that experimentation Is complex, however, will 
not make it undue if a person of skill in the art typically engages in such complex 
experimentation." 

Prior Art Rejections 
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Claims 1-23 stand rejected as being clearly anticipated by IEEE Std 1076.1-1999, 
March 18, 1999 (hereinafter "IEEE"). In making the rejection, the Examiner merely cited to 
pages 134-140, Section "9.5 Concurrent Signal Assignment Statements." The Examiner 
did not provide any explanation whatsoever for making the anticipation rejection. Instead, 
the Fvaminar repeatedly cited the same s even pages again and again for each Of 
several different limitations in Claim 1 . See the rejection of Claim 1 in the top half of 



page 5 of the Office Action. The Examiner did not identify with specificity the precise 
location within these seven pages as to where he/she thinks each individual particular 
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limitations is found. In view of the failure to artic ulate a basis for the rejection, Applicants 
submit that the anticipation rejection of Claim 1 should be withdrawn in its entirety. 

Assume arguendo that there is a reasonable basis for the anticipation rejection 
(although as noted above the Examiner's rejection lacks basis). However, Applicants 
submit that none of the limitations of Claim 1 are found anywhere in the entirety of the 
cited portion of the reference, namely the seven pages 134-140 in IEEE Section 9.5. The 
reason that none of the claimed limitations can be found in IEEE is because IEEE is a 
standard which merely savs what needs to be d one, without saving how to do it. In 
contrast, Claim 1 recites specific acts to be performed, i.e. how to do something. 

When the acts of Claim 1 are performed, certain embodiments of the invention 
conform to IEEE Section 15, pages 225-230. Note that this section 1 5 now being identified 
by Applicants is quite different from the section 9.5 cited by the Examiner. In view of the 
above-mentioned absence of an explanation for the rejection, it is unclear why the 
Examiner found pages 134-140 in IEEE Section 9.5 to be relevant. The Examiner appears 
to have correctly interpreted the functionality related to the invention in paragraph 3 on 
page 2 of the Office Action wherein the Examiner identified the functionality as 
"simultaneous statements". This very term "simultaneous statements" is found in the title 
of IEEE Section 15 on page 225. Yet the Examiner cited to IEEE Section 9.5 page 134 
which has a very different title, namely "Concurrent Signal Assignment Statements." If the 
Examiner continues the rejection, Applicants respectfully request the Examiner to clarify 
the record, so that an appropriate response can be filed. 

Moreover, the Examiner is respectfully requested to carefully evaluate the relevance 
of IEEE Section 15 to the claimed invention, in view of the above remark regarding the 
difference between a specification (of what needs to be done) and an implementation (of 
how to do it). In this context, Applicants note that a user may write a model (of 
simultaneous statements) that conforms to IEEE Section 15. How a given model performs 
(e.g. how quickly it operates or how much memory it uses) depends on the tool that is 
saieoNVAu^r use H { Q execute the model. Applicants submit that tools that perform the acts of Claim 1 

j mp | ernen t a n invention that is novel and non-obvious and worthy of patent protection. 
•£532S» Applicants are not attempting to patent the IEEE standard , but instead Claim 1 is 
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directed to specific acts to be performed (which implement the standard in some 
embodiments). 

In evaluating the relevance of IEEE, Applicants submit that the combination of acts 
recited in Claim 1 is neither disclosed nor suggested by IEEE Section 15, pages 225-230, 
or for that matter any other portion of IEEE Std 1076.1-1999. Nor for that matter does 
Claim 1 cover all possible ways in which IEEE Std 1076.1-1 999 can be implemented. For 
example, Claim 1 explicitly requires assigning a value for the active conditional equation to 
a dynamic slot target variable at the current analog solution iteration . Therefore, if 
another method were to use a static assignment scheme, in which slot assignments are 
unchanged regardless of the iteration, then such a method is not covered by Claim 1 but 
the method could yet be in compliance with IEEE Section 15, pages 225-230- [Ernst: 
Please confirm this is TRUE - we are agreeing that such a method will avoid patent 
infringement] Applicants note that neither a static assignment scheme nor a dynamic 
assignment scheme is disclosed in IEEE, because as noted above IEEE is merely a 
standard that does not describe any implementations. 

To summarize, none of the limitations of Claim 1 is believed to be described in 
IEEE. If the Examiner continues to make the anticipation rejection, the Examiner must 
provide a pinpoint citation for each claim limitation so that Applicants can respond 
appropriately. In considering the prior art, the Examiner is requested to understand the 
dynamic assignment invented by Applicants, wherein an assignment occurs in the 



current iteration (see page 9, lines 10-12 and act 115 discussed above in relation to the 



"assignment software"). The need for an Examiner to consider what Applicants have 
Invented, is stated in MPEP 2106 which is reproduced below in pertinent part (emphasis 
| added): 
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II. DETERMINE WHAT APPLICANT HAS INVENTED AND 
IS SEEKING TO PATENT 

It is essential that patent applicants obtain a prompt yet 
oomplete examination of their applications, ... Deficiencies 
should be explained dearly, particularly when they serve as 
a basis for a rejection. Whenever practicable, Office 
personnel should indicate how rejections may be 
overcome and how problems may be resolved. A failure to 
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follow this approach can lead to unnecessary delays in the 
prosecution of the application. 

Prior to focusing on specific statutory requirements, Office 
personnel must begin examination by determini ng what. 
precisely, the applicant has invented and is seeking to 
patent, and how the claims relate to and define that 
invention. (As the courts have repeatedly reminded the 
Office: "The goal is to answer the question What did 
applicants invent? 1 " In re Abele, 684 F.2d 902, 907, 214 
USPQ 682, 687. Accord, e.g., Arrhythmia Research Tech. v. 
Corazonix Corp., 958 F.2d 1053, 1059, 22 USPQ2d 1033, 
1038 (Fed. Cir. 1992).)... 

In determining what has been invented, the Examiner is requested to take into account the 
entirety of the originally-filed application. In view of the above remarks,* Applicants submit 
that the anticipation rejection of Claim 1 should be withdrawn. Claim 1 is therefore 
patentable over the prior art of record. 

Claims 2-23 were rejected for the very same reasons as Claim 1 , and are believed 
to be patentable also for the above discussed reasons. 

In rejecting Claims 2-23, the Examiner made no attempt whatsoever to precisely 
cite individual portions of IEEE that the Examiner thinks are more relevant to one claim as 
opposed to another claim. If the Examiner believes that all these claims have the same 
scope (despite their individual limitations) then the Examiner must explain the basis for 
such belief. For example, Claim 3 (which depends from Claim 2) explicitly recites the acts 
to be done at a second iteration (including an additional act of assigning). 

For the above reasons, Applicants respectfully request allowance of all Claims 1-23. 
Should the Examiner have any questions concerning this response, the Examiner is invited 
to call the undersigned at (408) 982-8200, ext. 3. 

Respectfully submitted, 
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